持续交付

持续交付是一种方法，团队通过自动化方式，从源代码存储库到生产环境，频繁且可预测地发布高质量产品。

一些组织采用人工方式发布产品，将产品从一个团队移交至另一个团队，具体流程如下图所示。通常，开发人员处于该流程的起始端，运营人员则处于接收端。这会在每一次移交环节产生延误，导致团队受挫、客户满意度下降。最终产品的上线流程繁琐且容易出错，进而延误收益的产生。

现在，请查阅下方的持续交付管道。该管道展示了开发人员如何在个人笔记本电脑上编写代码，并将代码变更提交至源代码存储库（如 Bitbucket）。此处所指的代码，包含被测系统、测试本身以及用于部署和维护该系统的基础架构。Bitbucket Pipelines 可将产品从测试环境推送至预发布环境，再到生产环境，助力客户快速体验各项全新亮眼功能。

持续交付管道可在投产前设置人工审核节点。人工审核节点需要人工介入，组织中部分场景的管道会要求设置这类节点。有些人工审核节点的必要性存疑，但有些则具备合理依据。其中一种合理场景是让业务团队拥有发布的最终决策权。工程团队在每个冲刺阶段结束后，都准备好一个可交付的产品版本，而业务团队则最终决定是向所有客户发布该产品，还是面向特定用户群体，或是针对特定地理区域的用户进行发布。

在管道中流转的产品架构是决定持续交付管道结构的关键因素。耦合度高的产品架构会形成复杂的管道图示模式，各类管道在最终进入生产环节前可能会相互交织。

产品架构还会影响管道的不同阶段，以及每个阶段产出的工件。管道首先会构建组件—即产品中最小的可分发、可测试单元。例如，由管道构建的类库即可被称为一个组件，这一环节就是组件构建阶段。

松耦合组件构成子系统—即最小的可部署、可运行单元。例如，一台服务器就是一个子系统，在容器中运行的微服务也属于子系统范畴。这一环节为子系统阶段。与组件不同，子系统可以独立启动并开展测试。

因此，若需将整个系统作为一个整体发布，可设定管道，使其基于松耦合子系统完成系统组装。这一环节为系统阶段。

这种“要么全部完成，要么全部搁置”的模式会导致速度最快的子系统被迫迁就最慢的子系统。我们常用“链条的强度取决于最薄弱的一环”这句老生常谈的话来提醒那些陷入这种架构模式的团队。

经过验证后，组装完成的系统会在最后一个阶段（称为生产阶段）直接推进至生产环境，且不会再做任何修改。

需要注意的是，这些阶段更多是逻辑层面的划分，而非物理层面的，划分的目的仅仅是将一个复杂的大问题拆解为多个更小的子问题。您可以根据自身的架构和需求，设置更少或更多的阶段。

脱离质量的速度对客户而言毫无价值。持续测试是一种将自动化测试与软件交付管道相集成的技术，能够对管道中流转的每一处变更进行验证。测试会在管道的每个阶段执行，以验证该阶段产出的工件。在管道的组件阶段，通过单元测试和静态代码分析验证组件；在子系统阶段，通过功能测试、性能测试和安全测试验证子系统；在系统阶段，通过集成测试、性能测试和安全测试验证系统；最后在生产阶段，通过冒烟测试验证产品。

软件交付管道本身就是一种产品，理应成为企业的优先事项。否则，就不该将创造收益的产品通过这条管道发布。持续交付从三个方面创造价值：提升软件开发团队的交付速度、工作效率与工作可持续性。

何时是采用持续交付的最佳时机？答案是昨天。
团队需要一个统一的、按优先级排序的产品待办事项列表，具体要求如下：

持续交付是正确的实践方向，有时需要推动者来启动转型。最终，当设计得当时，持续交付管道将收回成本。

那么，哪些人员需要参与其中呢？

部分组织会指派经验欠缺的人员来设计和实施持续交付管道，随后才艰难地认识到其中涉及的复杂性。安排初级成员负责此事，不仅会向团队传递错误信号，还意味着持续交付处于低优先级地位。我们强烈建议由资深架构师牵头负责，此人需对技术和业务都有深刻理解。

无论您在持续的一切（集成、测试、交付、部署、分析等）的旅程中处于哪个阶段，它既不是清单，也不是目标，并以持续改进作为核心。

迟早，在构建持续交付管道时，组织中的每个人都会接到电话。高管、工程、产品管理、治理、风险、合规、InfoSec、运营、法律以及您所拥有的一切。管道穿过孤岛并打破阻碍。不管怎样，我们所有人都是这种转型的一部分，持续的每个人都是新常态！